Computer networks have become ubiquitous in the home, office, and industrial environment. As computer networks have grown ever complex, automated mechanisms for organizing and managing the networks have emerged. These mechanisms are generally implemented in the form of one or more computer programs, and are generically known as network management systems or applications.
FIG. 1 is a simplified diagram of a network 100 that is managed by a network management system running on one or more network management stations 10. The network 100 comprises one or more network devices 102, such as switches, routers, bridges, gateways, and other devices. Each network device 102 is coupled to another network device 102, or to one or more end stations 120. Each end station 120 is a terminal node of the network 100 at which some type of work is carried out. For example, an end station 120 is a workstation, a printer, a server, or similar device.
Each network device 102 executes a network-oriented operating system 110. An example of a network-oriented operating system is the Internetworking Operating System (IOS) commercially available from Cisco Systems, Inc. Each network device 102 also executes one or more applications 112 under control of the operating system 110. The operating system 110 supervises operation of the applications 112 and communicates over network connections 104 using one or more agreed-upon network communication protocols, such as Simple Network Management Protocol (SNMP).
Each device 102 stores information about its current configuration, and other information, in one or more forms, for example, a Management Information Base (MIB) 114. Information in the MIB 114 is organized in one or more MIB variables. The network management station 10 can send "fetch" and "set" commands to the device 102 in order to retrieve or set values of MIB variables. Examples of MIB variables include sysObjectID and sysDescr. For information stored in other forms, there are other types of communications and commands to set and retrieve the information values.
Preferably the network management station 10 is a general-purpose computer system of the type shown and described further herein in connection with FIG. 3. The network management station 10 executes one or more software components that carry out the functions shown in block diagram form in FIG. 1. For example, the network management station 10 executes a basic input/output system (BIOS) 20 that controls and governs interaction of upper logical layers of the software components with hardware of the network management station. An example of a suitable BIOS is the Phoenix ROM BIOS. The network management station 10 also executes an operating system 30 that supervises and controls operation of upper-level application programs. An example of a suitable operating system is the Microsoft Windows NT.RTM. operating system. The network management station 10 may also execute other operating systems that may not require a BIOS 20, such as UNIX-type operating systems, microkernel-based operating systems, etc.
The network management station 10 executes an asynchronous network interface (ANI) 50 under control of the operating system 30. The ANI 50 provides an interface to the network 100 and communicates with the network using SNMP or other agreed-upon protocols. The ANI 50 provides numerous low-level services and functions for use by higher-level applications.
The network management station 10 executes a network management system 40 that interacts with an information base 60 containing information about the managed network 100. The information base may be implemented on one or more of: relational data bases, object data bases, directories, flat file systems, ISAM file systems, etc. The network management system 40 is an example of a network management application. Using a network management application, a manager can monitor and control network components. For example, a network management application enables a manager to interrogate devices such as host computers, routers, switches, and bridges to determine their status and to obtain statistics about the networks to which they attach. The network management application also enables a manager to control such devices by changing device configuration or operation information, for example, routes and configuring network interfaces. Examples of network management applications are CiscoWorks, CiscoWorks 2000, and CiscoView, each of which is commercially available from Cisco Systems, Inc.
The ANI 50 and network management system 40 need not execute or reside on the same physical computer. They may execute on different machines. There need not be only one ANI 50 or only one network management system 40.
The behavior of some network management applications or equipment may be governed by one or more abstract policies. A network management policy expresses a business goal for use of the network; the network management application can convert the policy into instructions to network devices, such as switches, routers, and other hardware and software, to implement the policy. An example of a policy is: "All administrative assistants may use the World Wide Web only between 11 a.m. and 3 p.m., Monday through Friday." A system that can receive and act on such policies is sometimes called a policy-based network management system.
Policy-based management is used in other, specific contexts within the broad field of network management. For example, Cisco Centri Firewall software product, commercially available from Cisco Systems, Inc. of San Jose, Calif., is a policy-driven product. The use of policies to control a firewall is disclosed in co-pending U.S. patent application Ser. No. 60/074945, filed Feb. 17, 1998, entitled "Graphical Network Security Policy Management," and naming Scott L. Wiegel as inventor.
Other information about policy-based networking is described in CiscoAssure Policy Networking: Enabling Business Applications through Intelligent Networking, http://www.cisco.com/warp/public/734/capn/assur sd.htm (posted Jun. 13, 1998); CiscoAssure Policy Networking End-to-End Quality of Service, http://www. cisco.com/ warp/public/734/capn/cagos wp.htm (posted Jun. 24, 1998); Delivering End-to-End Security in Policy-Based Networks, http://www.cisco. com/warp/public/734/capn/deesp wp.htm (posted Sep. 11, 1998); User Registration and Address Management Services for Policy Networking, http://www.cisco.com/warp/public/ 734/capn/polnt wp.htm (posted Sep. 11, 1998); CiscoAssure User Registration Tool, http://www.cisco.com/warp/public/734/capn/caurt ai.htm (posted Oct. 8, 1998).
Not all existing networks, however, use policy-based networking. A large number of networks and network devices that are installed in the field do not have policy-based network management systems. Policy-based network management systems are being rapidly added to such networks; however, there is a risk that the policy-based network management system will damage the network or erroneously configure network devices, because the policy-based network management system does not fully understand the current configuration of the network. To convert a non-policy-based network to a network with a policy-based network management system, an administrator may have to or want to manually write, evaluate, and verify one or more policies that reflect the actual configuration of the system. There is a risk that a policy will attempt to make a change to the network that cannot be satisfied by the network or is infeasible.
For example, a policy-based management system may assume the availability of access control lists within a particular range of values for its own purposes, regardless of whether another system is using the same range for a different purpose. In the prior approaches, the management system essentially forces the managed system to use the range of values required by the management system, because the management system has no way to find out that another system previously has used a conflicting range.
As another example, the specifications for a particular set of network devices may dictate that if the devices are configured to execute weighted random early discard on a particular interface, the devices cannot concurrently do priority queuing, and that only weighted fair queuing may be used at the same time. Then a policy is installed that requests priority queuing in violation of such specifications. Suddenly, the network does not work as intended, perhaps in an undefined way, simply because the policy-based system did not determine the configuration requirements of the network before enforcing the policy.
Based on the foregoing, there is a clear need in this field for a policy-based network management system to automatically understand the configuration of an existing network.
Moreover, even in a network system that does use policy-based networking and is largely or completely configured using policies, it is still safer and easier to manage using policies when the policy system can understand the existing configuration. Thus, there is a need to provide such policy-based networking systems with an automatic way to detect and understand the current network configuration.
In the prior approaches, when a policy is manually prepared and intended to reflect the configuration of a non-policy-based network, the administrator has no easy way to verify that the new policy will work with the equipment and services to which it is to be applied. Thus, there is also a need for an automatic way to determine when one policy satisfies the capabilities of the equipment and services to which it is to be applied.
Another disadvantage of the prior approaches is that there is no way to determine whether the manually prepared policy is "feasible" when the network is in operation. For example, the network may have sufficient resources to satisfy a particular request, but insufficient resources to satisfy all the possible number of requests, such that the policy is infeasible. Thus, there is also a need for an automatic way to determine when one policy is feasible.
Still another disadvantage of the prior approaches is that there is no way to compare the requirements, constraints and configurations specified by the result or "consequent" of a policy with the actual configurations present in the network, its equipment or services. For example, an administrator may manually prepare a policy that says, "Upon condition X, set up service Y," but the network under management has no way to set up service Y. Therefore, there is a need for an automatic way to verify that the configuration demanded by a policy is possible, and to report differences and discrepancies in what the policy demands compared to what is possible in the network.
The foregoing needs exist in any policy-based system, not just in policy-based network systems. There is a particular need, however, for such a system, mechanism or process that can be used in the context of a network management application that manages a network of data communication devices or computer devices.